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REMARKS 

This Amendment is filed in response to the Office Action 
dated June 16, 2005, which has a shortened statutory period set 
to expire September 16, 2005. 

Rejections Under 35 U.S.C. 112 

Claims 1-27 and 30-35 stand rejected under 35 U.S.C. 112, 
first paragraph, as failing to comply with the written 
description requirement. Applicant respectfully traverses this 
rejection in light of the following remarks. 

The Office Action indicates that the limitation "at the 
computer based phone application platform" as recited in Claim 1 
does not appear in the specification. However, this limitation 
is specifically described with respect to FIG. 1 (duplicated 
here for reference) . 
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As noted in the specification as originally filed: 

In this instance the application file 114 is 
identified by the URI <http : //www, valdemar . net/erik/ 
grocery .vxml> . The URI serves as a reference, or pointer, 
to the actual application code for the phone application 
platform 110. ... Upon submission, the development platform 
web server 108 sends appropriate messages and/or updates 
suitable shared data, e.g. in the shared database 112, to 
notify the phone application platform 110 to make the 
referenced phone application available. (Specification, 
page 33, lines 2-14, emphasis added.) 

Thus, during URI based development, "the URI application is 

'live' on the phone application platform 110." (Specification, 

page 34, lines 8-9, emphasis added.) Therefore, "receiving the 

phone application code at the computer based phone application 

platform over the network interface from a remote computer via a 

development platform web server and using a web protocol" as 

recited by Claim 1 is fully supported in the specification. 

Furthermore, Claim 1 as originally filed recited: 

A method of supporting development of a phone 
application code for a computer based phone application 
platform having a network interface and a telephone 
interface, the method comprising . . . receiving over the 
network interface from a remote computer the phone 
application code. (Emphasis added.) 

Thus, Claim 1 as originally filed provides explicit indication 
that at the time the invention was filed. Applicants had 
possession of the claimed invention related to the limitation 
"at the computer based phone application platform" associated 
with Claims 1-27 and 30-35. 

The Office Action further rejects Claims 30-35 under 35 
U.S.C. 112, first paragraph as failing to comply with the 
written description requirement for the reason that the " [n] ewly 
claimed subject matter is not found in Applicant cited portions 
of specification." Applicants respectfully traverse these 
rejections in light of the following remarks. 
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claim 30 recites: 

The method of claim 1, wherein associating the phone 
application code with the telephone number comprises 
associating a uniform resource identifier (URI) with the 
telephone number, the URI serving as a pointer to the phone 
application code. 

As noted in the specification as originally filed: 

The URI serves as a reference, or pointer, to the 
actual application code for the phone application platform 
110. According to some embodiments of the invention, a 
developer makes her/his application available for testing 
at the call in number 302 by sxibmitting the URI to the 
development platform web server 108." (Specification, page 
33, lines 6-9, emphasis added.) 

Thus, Claim 30 is fully supported in the specification as 
originally filed. 

Claim 31 recites: 

The method of claim 30, wherein receiving the phone 
application code at the computer based phone application 
platform comprises: 

at the computer based phone application platform, 

responsive to receiving the telephone call via the 

telephone number, accessing the phone application code 

via the URI . 

As noted in the specification as originally filed, " [a] ccording 
to some embodiments of the invention, a developer makes her/his 
application available for testing at the call in number 302 by 
siibmitting the URI to the development platform web server 108." 
(Specification, page 33, lines 7-10, emphasis added.) As shown 
in FIG. 3 (duplicated here for reference), once the "Application 
URI 304" is submitted, it is accessible by calling "Call in 
Number 302", as indicated by the text "Enter the UL to your VXML 
below, and call l-800-756-#### to preview it." 
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Thus, Claim 31 is fully supported in the specification as 

originally filed. 

Claim 32 recites: 

The method of claim 7, wherein associating the phone 
application code with the telephone number comprises 
associating a uniform resource identifier (URI) with the 
telephone number, the URI serving as a pointer to the phone 
application code. 

For substantially the same reasons as those presented above for 
Claim 30, Claim 32 is fully supported by the specification as 
originally filed. 

Claim 33 recites: 

The method of Claim 32, wherein receiving the phone 
application code at the computer based phone application 
platform comprises: 

at the computer based phone application platform, 

responsive to receiving the telephone call via the 

telephone number, accessing the phone application code 

via the URI . 



15 



(SN: 09/592, 241) 



For reasons substantially similar to those presented above for 

Claim 31, Claim 33 is fully supported by the specification as 

originally filed. 

Claim 34 recites: 

The method of Claim 10, wherein associating the phone 
application code with the telephone number comprises 
associating a uniform resource identifier (URI) with the 
telephone number, the URI serving as a pointer to the phone 
application code. 

For reasons substantially similar to those presented above for 

Claim 30, Claim 34 is fully supported by the specification as 

originally filed. 

Claim 35 recites: 

The method of Claim 34, wherein executing the phone 
application code comprises: 

at the computer based phone application platform, 
responsive to receiving the telephone call via the 
telephone number, accessing the phone application code 
via the URI . 

For reasons substantially similar to those presented above for 
Claim 31, Claim 35 is fully supported by the specification as 
originally filed. 

Claims 1-27 and 30-35 stand further rejected under 35 
U.S.C. 112, first paragraph, as failing to comply with the 
enablement requirement. However, for at least the reasons 
presented above with respect to Claims 1-27 and 30-35, the 
subject matter of Claims 1-27 and 30-35 is fully enabled by the 
application as originally filed. 

Accordingly, Applicants respectfully request 
reconsideration and withdrawal of the rejections of Claims 1-27 
and 30-35 under 35 U.S.C. 112, first paragraph. 
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Rejections Under 35 U.S.C. 103 

Claims 1-2, 4-7, 9-17, 19-21, 24-26, and 28-35 stand 
rejected under 35 U.S.C. 103(a) as being unpatentable over Leask 
in view of House. Applicants respectfully traverse these 
rejections in light of the following remarks. 

Claim 1 recites: 

A method of supporting development of a phone 
application code for a computer based phone application 
platform having a network interface and a telephone 
interface, the method comprising: 

receiving the phone application code at the 
computer based phone application platform over the 
network interface from a remote computer via a 
development platform web server and using a web 
protocol; 

associating the phone application code with a 
telephone number for communicating with the telephone 
interface; and 

at the computer based phone application platform, 
responsive to receiving a telephone call via the 
telephone number, 

executing the phone application code; 

presenting an audio output over the telephone 
interface; and 

presenting a call flow to the remote computer 
over the network interface via the development 
platform web server and using the web protocol, the 
call flow tracking a flow of execution for a phone 
call. (Emphasis added.) 

"[Rjeceiving the phone application code at the computer based 
phone application platform . . . from a remote computer , . . [and 
then] at the computer based phone application platform . . . 
executing the phone application code" as recited in Claim 1, 
beneficially provides an environment in which "developers, or 
programmers, [can] easily create phone applications without the 
need for specialized hardware or software on their local 
machines." (Specification, page 11, lines 5-7.) 

The Office Action indicates that the "receiving the phone 
application code at the computer based phone application 
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platform over the network interface from a remote computer" as 
recited by Claim 1 is taught by "column 7, line 65 to column 8, 
line 6; column 18, lines 26-41" of Leask. Applicants 
respectfully submit that this is an improper interpretation of 
Leask. 

The Office Action cites a portion of Leask that states: 

Still a further technical advantage of one aspect of 
the present invention is that a system and method for 
debugging computer programs graphically are provided 
wherein an application that is stored and/or executing 
remotely can be debugged utilizing a debugging program that 
is executing locally. Accordingly, a debugging program is 
not required to be executing at each remote site where an 
application program is stored and/or executing. (Leask, 
col. 7, line 65 to col. 8, line 6.) 

This cited portion of Leask merely mentions a "remote site where 
an application program is stored and/or executing", and does not 
disclose or suggest "receiving the phone application code at the 
computer based phone application platform over the network 
interface from a remote computer" (emphasis added) as recited by 
Claim 1. 

In a similar vein, Leask further recites: 

Turning back now to FIG. 1, in a preferred embodiment 
of the present invention, the graphical debugging program 
is executed locally, such as on computer system IOOlocal- 
Further, in a preferred embodiment, an application program 
to be debugged may be stored either locally, such as on 
computer system IOOx^ocal/ or remotely, such as on computer 
system IOOremote- If the application program is stored 
remotely at system IOOremotef a graphical representation of 
the application program may be retrieved via network 108 
and displayed locally at computer system IOOlocal- 
Thereafter, the. application program may be debugged 
utilizing the graphical debugging environment running 
locally on computer system IOOlocal- That is, the graphical 
debugging program may be utilized locally at computer 
system IOOlocal to insert debug tools, such as breakpoints, 
for the remote application program. (Leask, col. 18, lines 
26-41 . ) 
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Here, Leask only states that "If the application program is 
stored remotely at system lOOREMorsi a graphical representation of 
the application program may be retrieved via network 108 and 
displayed locally at computer system IOOlocal-" (Emphasis added.) 
System IOOlocal of Leask is a "local personal computer system" 
(Leask, col. 8, lines 62-63) and nowhere is described as a 
"computer based phone application platform" as recited by 
Claim 1. 

Furthermore, even assuming, arguendo, that System IOOlocal 
could be considered to be a "computer based phone application 
platform" as recited by Claim 1, Leask merely teaches 
" [retrieving] a graphical representation of the application 
program ... via network 108" (Leask, col. 18, lines 33-35) and 
does not disclose or suggest "receiving the phone application 
code at the computer based phone application platform over the 
network interface from a remote computer" (emphasis added) as 
recited by Claim 1. 

The Office Action states that " [r] eceiving a graphical 
representation of a program is receiving the phone application 
code. The representation must include code if it is to be 
debugged." Applicants respectfully submit that this is an 
incorrect assertion. As is well known in the art, the graphical 
representation of a program certainly does not require receiving 
actual application code. For example, a "thin client" can 
display graphical representations of application code running on 
an application server (see, for example, Wikipedia definition at 
http://en.wikipedia.org/wiki/Thin client) . By explicitly 
teaching " [retrieving] a graphical representation of the 
application program ... via network 108" (Leask, col. 18, lines 
33-35) , Leask actually teaches away from "receiving the phone 
application code at the computer based phone application 
platform" (emphasis added) as recited by Claim 1. 
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Furthermore, debugging certainly does not require that code 
be included in the graphical representation. In fact, Leask 
states that "the graphical debugging program may be utilized 
locally ... to insert debug tools, such as breakpoints, for the 
remote application program." (Leask, col- 18, lines 38-41, 
emphasis added.) Here too, Leask teaches away from "receiving 
the phone application code at the computer based phone 
application platform" as recited by Claim 1. 

The Office Action further indicates that "at the computer 
based phone application platform, responsive to receiving a 
telephone call via the telephone number, executing the phone 
application code" (emphasis added) as recited by Claim 1 is 
taught by Leask at column 18, lines 42-44 and column 16, lines 
47-49. Applicants respectfully submit that this is an improper 
interpretation of Leask. 

Column 18, lines 42-44 of Leask recite that "[m]oreover, in 
a preferred embodiment, the graphical debugging environment 
allows a developer to debug an application program during the 
application's runtime", while column 16, lines 47-49 of Leask 
recite that "the icon currently being executed may be 
highlighted or otherwise indicated to allow a developer to 
monitor the progress of the program's execution." In both 
cases, the activity is described within the graphical debugging 
environment of Leask, which is only described as running on 
local system IOOlocal (e.g., "Accordingly, the graphical 
debugger program running on local computer IOOlocal n^ay 
be utilized to debug locally stored programs or programs 
stored at remote locations (e.g., IOOremote) via network 
108." Leask, col. 10, lines 4-8.). 

In neither of these cited portions of Leask (nor in any 
non-cited portion of Leask) is it disclosed or suggested that 
local system IOOlocal can be considered "the computer based phone 
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application platform" recited by Claim 1. Furthermore, even 
assuming, arguendo, that local system IOOlocal can be considered a 
"computer based phone application platform" as recited by Claim 
1, Leask does not disclose or suggest that local system IOOlocal 
includes a "telephone interface" as recited by Claim 1, 
Therefore, Leask certainly does not teach "at the computer based 
phone application platform, responsive to receiving a telephone 
call via the telephone number, executing the phone application 
code" (emphasis added) as recited by Claim 1. 

House does not remedy any of these deficiencies of Leask. 
House describes a "network server 110 [that] comprises a web 
server 502 . . . [that] provides access between the network server 
110 and the user computers 104 [, and] an application server 504 
for running the applications (shown in FIG. 1 as 112)." House 
does not disclose or suggest that network server 110 includes a 
"telephone interface" as recited by Claim 1, and so does not 
teach a "computer based phone application platform" as recited 
by Claim 1 . 

However, even assuming, arguendo, that network server 110 
of House can be considered a "computer based phone application 
platform" as recited by Claim 1, House teaches a system in which 
applications are housed and executed within a network server, 
and consequently teaches away from "receiving the phone 
application code at the computer based phone application 
platform over the network interface from a remote computer" 
(emphasis added) as recited by Claim 1. 

Furthermore, because House does not disclose or suggest any 
telephone-based interaction, and House certainly does not teach 
"at the computer based phone application platform, responsive to 
receiving a telephone call via the telephone number, executing 
the phone application code" (emphasis added) as recited by 
Claim 1. 
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In addition, while the Office Action indicates that House 
teaches "receiving the phone application code at the computer 
based phone application platform over the network interface from 
a remote computer via a development platform web server and 
using a web protocol" (emphasis added) as recited by Claim 1, 
Applicants respectfully submit that House provides no such 
teaching. House does not disclose or suggest a "development 
platform web server" as recited in Claim 1, and actually teaches 
away from such a web server by incorporating application server 
504 into network server 110. 

Thus, for at least these reasons, Claim 1 is allowable 
under 35 U.S.C. 103(a) over Leask in view of House. Claims 2, 
4-6, 30, and 31 depend from Claim 1, and are therefore allowable 
over Leask in view of House for at least the same reasons that 
Claim 1 is allowable. Accordingly, Applicants respectfully 
request reconsideration and allowance of Claims 1-2, 4-6, 30, 
and 3 1 . 

In addition. Claim 30 recites "associating a uniform 
resource identifier (URI) with the telephone number, the URI 
serving as a pointer to the phone application code." The Office 
Action indicates that this limitation is taught by House, but no 
such support is found in the cited portions of House. In fact. 
House explicitly describes that "[t]he help desk technician 114 
answers the call, and asks the user 102 for the URL" (House, 
col. 5, lines 22-23, emphasis added), and therefore teaches away 
from "associating a uniform resource identifier (URI) with the 
telephone number, the URI serving as a pointer to the phone 
application code" as recited by Claim 30. For at least this 
additional reason, Claim 30 is further allowable over Leask in 
view of House . 

Likewise, Claim 31, which recites "at the computer based 
phone application platform, responsive to receiving the 
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telephone call via the telephone number, accessing the phone 
application code via the URI", is further allowable over Leask 
in view of House, since as described above with respect to Claim 
30, House teaches a method in which a ''helpdesk technician" 
provides manual URL selection. 

Claim 7 is allowable under 35 U.S.C. 103(a) over Leask in 
view of House for reasons substantially similar to those 
provided with respect to Claim 1. Claims 9, 32, and 33 depend 
from Claim 7, and are therefore allowable over Leask in view of 
House for at least the same reasons that Claim 7 is allowable. 
Note that Claims 32 and 33 are further allowable over Leask in 
view of House for at least the reasons presented above with 
respect to Claims 3 0 and 31, respectively. Accordingly, 
Applicants respectfully request reconsideration and allowance of 
Claims 7, 9, 32, and 33. 

Claim 10 is allowable under 35 U.S.C. 103(a) over Leask in 
view of House for reasons substantially similar to those 
provided with respect to Claim 1. Claims 11-14, 34, and 35 
depend from Claim 10, and are therefore allowable over Leask in 
view of House for at least the same reasons that Claim 10 is 
allowable. Note that Claims 34 and 35 are further allowable 
over Leask in view of House for at least the reasons presented 
above with respect to Claims 30 and 31, respectively. 
Accordingly, Applicants respectfully request reconsideration and 
allowance of Claims 10-14, 34, and 35. 

Claim 15 is allowable under 35 U.S.C. 103(a) over Leask in 
view of House for reasons substantially similar to those 
provided with respect to Claim 1. Claims 16-17, 19-21, and 24- 
26 depend from Claim 15, and are therefore allowable over Leask 
in view of House for at least the same reasons that Claim 15 is 
allowable . Accordingly, Applicants respectfully request 
reconsideration and allowance of Claims 15-17, 19-21, and 24-26. 
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Claim 28 is allowable under 35 U.S.C. 103(a) over Leask in 
view of House for reasons substantially similar to those 
provided with respect to Claim 1, Accordingly, Applicants 
respectfully request reconsideration and allowance of Claim 28. 

Claim 29 is allowable under 35 U.S.C. 103(a) over Leask in 
view of House for reasons substantially similar to those 
provided with respect to Claim 1. Accordingly, Applicants 
respectfully request reconsideration and allowance of Claim 29. 

Claims 3, 8, and 22 stand rejected under 35 U.S.C. 103(a) 
as being unpatentable over Leask in view of House and further in 
view of the "Dictionary of Computing", Fourth Edition, Oxford 
University Press, 1996 (hereinafter "Dictionary") . Applicants 
respectfully traverse these rejections in light of the above 
amendments to the claims and the following remarks. 

As noted above, Leask in view of House does not teach or 
suggest : 

[R] eceiving the phone application code at the computer 
based phone application platform over the network interface 
from a remote computer via a development platform web 
server and using a web protocol . . . and 

at the computer based phone application platform, 
responsive to receiving a telephone call via the telephone 
number, executing the phone application code. (Emphasis 
added , ) 

The cited portion of Dictionary simply recites a definition of a 
"trace program" , and therefore does not remedy the deficiencies 
of Leask and House . 

Claim 3, which depends from Claim 1, is therefore allowable 
over Leask in view of House and further in view of Dictionary . 
Accordingly, Applicants respectfully request reconsideration and 
allowance of Claim 3 . 

Similarly, Dictionary does not remedy the deficiencies of 
Leask and House with respect to Claim 7, from which Claim 8 
depends. Therefore, Claim 8 is allowable over Leask in view of 
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House and further in view of Dictionary. Accordingly, 
Applicants respectfully request reconsideration and allowance of 
Claim 8. 

Similarly, Dictionary does not remedy the deficiencies of 
Leask and House with respect to Claim 15, from which Claim 22 
depends. Therefore, Claim 22 is allowable over Leask in view of 
House and further in view of Dictionary. Accordingly, 
Applicants respectfully request reconsideration and allowance of 
Claim 22 . 

Claims 18 and 27 stand rejected under 35 U.S.C. 103(a) as 
being unpatentable over Leask in view of House and further in 
view of "VoxML 1.0 Application Development Guide" (hereinafter 
"VoxML") . Applicants respectfully traverse these rejections. 

For reasons substantially similar to those provided above 
with respect to Claim 1, Leask in view of House does not teach 

receiving at the first computer system over the web 
interface a uniform resource identifier (URI) from a second 
computer system, the URI corresponding to a location of a 
phone appl i cat ion ; 

at the first computer system, responsive to the 
receiving the URI, sending a first message to the phone 
application platform using the first computer system, the 
first message corresponding to a request to make the phone 
application located at the URI available on the phone 
application platform at a telephone number." (Emphasis 
added. ) 

as recited by Claim 15. As noted by the Office Action, VoxML 
describes "a phone application written in an XML based voice 
language" . However, VoxML does not remedy the above-described 
deficiencies of Leask and House with respect to Claim 15, and 
therefore, Claims 18 and 27, which depend from Claim 15, are 
allowable under 35 U.S.C. 103(a) over Leask in view of House and 
further in view of VoxML. Accordingly, Applicants respectfully 
request reconsideration and allowance of Claims 18 and 27. 
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Claim 23 stands rejected under 35 U.S.C. 103(a) as being 
unpatentable over Leask in view of House and further in view of 
U.S. Patent No. 6,232,984, issued May 15, 2001 to Chuah et al . 
(hereinafter "Chuah"). Applicants respectfully traverse this 
rejection in view of the above amendments and the following 
remarks . 

As noted above, Leask in view of House does not teach 

receiving at the first computer system over the web 
interface a uniform resource identifier (URI) from a second 
computer system, the URI corresponding to a location of a 
phone appl icat ion ; 

at the first computer system, responsive to the 
receiving the URI, sending a first message to the phone 
application platform using the first computer system, the 
first message corresponding to a request to make the phone 
application located at the URI available on the phone 
application platform at a telephone number." (Emphasis 
added.) 

as recited by Claim 15. Chuah only teaches a "data 
visualization system for visually displaying large amounts of 
data, e.g., related to a software project, accumulated over a 
period of time" (Chuah, col. 2, lines 33-35), and does not 
remedy the above -described deficiencies of Leask and House with 
respect to Claim 15. Therefore, Claim 23, which depends from 
CI aim 15, is allowable under 35 U.S.C- 103 (a) over Leask in view 
of House and in further view of Chuah. Accordingly, Applicants 
respectfully request reconsideration and allowance of Claim 23. 
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CONCLUSION 



Claims 1-35 are pending in the present Application. 
Reconsideration and allowance of these claims is respectfully 
requested. 

If there are any questions, please telephone the 
undersigned at (408) 451-5903 to expedite prosecution of this 
case . 



I hereby certify that this correspondence is being deposited 
with the United States Postal Service as FIRST CLASS MAIL in 
an envelope addressed to: Mail Stop AF, Commissioner for 
Patents, P.O. Box 1450, Alexandria, VA 22313-1450 on September 
16, 2005. 



Respectfully submitted, 
/John M. Kubodera/ 



Customer No. : 24488 



John M. Kubodera 
Attorney for Applicant (s) 
Reg. No. 45,984 



Date 




Signature: Reoecca A. Baumann 
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